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Chapter 1 

Getting Started _ 

This document provides a demonstration of the Applied 
Microsystems SuperTAP system integration tool with 
MWX-ICE debugger. It assumes the SuperTAP and debugger 
are installed and the debugger is connected to the emulator, 
described in the Emulator Installation Guide and Chapter 2 of 
the MWXJCE User's Manual. 


Applied Microsystems Corporation 

Founded in 1979, Applied Microsystems is a leading ISO 9002- 
certified provider of integrated development systems for 
embedded microprocessor design. The company helps 
engineers develop and test quality products faster, more 
reliably, and at a lower cost through a growing family of 
compatible design tools. 

Why choose Applied Microsystems for my Motorola project? 

Applied Microsystems is an experienced and innovative leader 
in the field of microprocessor development tools. Motorola 
realized this when they made Applied Microsystems a 
preferred Motorola "Platinum” development tools partner. 

Applied Microsystems has a long and successful record 
supporting Motorola microprocessors; from the 6809 to 
PowerPC. Over 17 years experience with Motorola 
microprocessors lets us provide tools with the critical features 
necessary to debug today’s complex software appHcations in 
high performance embedded systems. 

First and fastest. Applied gave the industry its first 33 Mhz 
68020/030 emulator, its first 40 MHz 68040 emulator, and its 
first 66 MHz 68060 emulator. 
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Customer support 


Committed to your success 

Good support is as critical a part of your development system 
as the emulator or the debugger. Applied Microsystems 
Customer Support department employs a large staff of 
engineers and offers a full range of timely and effective support 
services. 

Contacting Customer Support 

PHONE: If you encounter trouble while evaluating this 
product, call Customer Support at 1-800-ASK-4AMC (1-800- 
275-4262). 

FAX: To FAX Apphed Microsystems, dial 1-206-883-3049. 

EMAIL: If you have access to the internet, you can contact 
Apphed Microsystems by sending email to support@amc.com. 

WWW: Apphed Microsystems maintains a World Wide Web 
site located at URL http://www.amc.com. 



Demonstration overview 

Chapter 1 of this guide introduces you to the SuperTAP and 
MWX-ICE debugger. After a product description, you start the 
debugger and become famihar with using its windowing 
system, load the demonstration program, and display 
SuperTAP configuration information. You must complete all of 
Chapter 1 before doing any of the examples in Chapter 2. 
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Running the examples 

Chapter 2 contains examples demonstrating basic debugger 
operation and key debugging features of Applied Microsystems 
SuperTAP. The examples are organized into functional groups, 
with each group prefaced by a brief discussion of the function. 

How long does it take? 

It takes approximately two hours to complete all the examples. 
However, the examples are not interdependent; you can choose 
to run, in any sequence, the examples that most interest you. 

You must complete each step within an example. The final 
steps of an example return settings to their original value, so 
you can do the examples in any order. 

Running in other targets 

The Cdemon demonstration code used in this guide was 
written for the Applied Microsystems demonstration board. 
Cdemon is loaded into emulator memory which has been 
configured (mapped) to replace (overlay) tlie desired address 
spaces of target memory. Because the program runs in overlay 
memory, the demonstration can be run without a target, with 
the emulator in isolation mode. 

Although the program runs in overlay memory, all write cycles 
still go out to the target. The demonstration can be nm in other 
embedded targets if the following memory considerations pose 
no problem: 

address range type of memory 

0x000000 - OxOlffffread/write 
0x100000 - 0xl7f£££read/write 
OxleOOOO - Oxl£££££read/write 


Demonstration overview 
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Evaluation Guide conventions 

Throughout the guide, an arrow in the margin indicates the 
beginning of procedures that you should follow. Below is an 
example of this type of procedure. (Do not follow the procedure 
at this time). 

> To restart the Cdemon program: 

■ In the Command window Enter Command box, enter: 
restart 



The frog in the margin indicates that a feature is unique to 
Applied Microsystems products, and provides considerable 
benefit to you in debugging. 



Warning messages appear before procedures and alert you to the 
danger of personal injury which may result unless certain 
precautions are observed. 


Caution 



Caution messages appear before procedures and indicate that 
damage may be done to the emulator or to your target system 
unless certain steps are observed. 


Note 



Notes indicate important information for the proper operation 
and installation of your emulator. 
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Radio interference warning 

This equipment generates, uses, and can radiate radio 
frequency energy. 


A This instrument is intended for use in the development of 

Caution / |\ microprocessor-based systems. At this stage of development, 
/ ^ \ these target devices typically include no inherent design to 
^^ limit the emissions of electromagnetic energy. 

Precautions should be taken to prevent harmful radiation to 
radio commxmications and other nearby sensitive electronic 
systems by means of isolation, separation, or shielding, where 
necessary. 

Use of this instrument in a residential area is likely to cause 
harmful interference, in which case, the user will be required 
to correct the interference at his own expense. 


FCC Rules 

It is temporarily permitted by regulation and has not been 
tested for compliance with the limits of Class A computing 
devices pursuant to Subpart J of Part 15 of FCC Rules, which 
are designed to provide reasonable protection against such 
interference. 

EMC Directive 

For compliance to the essential requirements of the EMC 
Directive 89/336/EEC, if a ground post is provided on the back 
of the chassis or on the external power supply, a properly 
bonded ground strap must be connected to it. 


Radio interference warning 
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Operating requirements 

Before setting up the SuperTAP, you should make sure that the 
operating environment is prepared. 


A CE-compliant systems: The AC third wire ground (safety 

Caution / f \ ground) is not connected to the emulator’s digital ground. For 

/ I \ proper operation, your target’s safety ground and digital 

^ -^ ground should not be connected. If they are connected, 

operation will result in the emulators DC voltage fiises (if any) 
blowing. If the target power supply’s digital ground cannot be 
isolated from the safety ground, then temporarily connect a 
wire between the ground stud on the emulator external power 
supply and target digital ground. This ground wire is in 
addition to the ground wire between the power supply ground 
stud and AC ground that is required for CE comphance and is 
described later in this manual. 

Under no circumstances should the third wire prong on the 
emulator power cord be removed or disconnected. 



Non-CE-compliant systems: The AC third wire ground 
(safety ground) is connected to the emulator’s digital ground. 
For proper operation, your target’s safety ground and digital 
ground should also be connected. If they are not connected, the 
DC voltage fuses (if any) in the target or in the target power 
supply may blow. For correct operation, coimect your target’s 
safety groxmd and digital ground. 

Under no circumstances should the third wire prong on the 
emulator power cord be removed or disconnected. 
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A Be sure the emulator and target are plugged into outlets that 

Caution / |\ have good electrical continuity on the third wire safety ground. 

/ I \ there is high electrical resistance on the safety grounds of 

^ -^ either or both the target power supply and emulator power 

supply, unwanted ground current may be drawn through the 
emulator probe, damaging the emulator or target system. 
Good electrical continuity is also required to maintain the 
EN55022 Class B Conducted Radiation Specification of the 
emulator power supply. 


Standard electrostatic precautions 

This instrument contains static-sensitive components that are 
subject to damage from electrostatic discharge. Use standard 
ESD precautions when transporting, handling, or using the 
instrument and the target, when connecting/disconnecting the 
instrument and the target, and when removing the cover of the 
instrument. 

Applied Microsystems recommends the use of the following 
precautions: 

□ Use wrist straps or heel bands with a 1 Megohm resistor 
connected to groimd. 

□ On the work surface and floor, use static conductive mats 
with a 1 Megohm resistor connected to ground. 

□ Keep high static-producing items, such as non-ESD- 
approved plastics, tape and packaging foam, away from the 
instrument and the target. 

The above precautions should be considered as minimum 
requirements for a static-controlled environment. 


Operating requirements 
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A The emulator contains components that are subject to damage 
from electrostatic discharge. Whenever you are using, 
handling, or transporting the emulator, or connecting to or 
disconnecting from a target system, always use proper anti¬ 
static protection measures, including static-free bench pads 
and groxmded wrist straps. 
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Product overview 


The SuperTAP is a complete tool for system debugging and 
integration. You can use SuperTAP and MWX-ICE in full in- 
circuit emulation mode to bring up your target hardware, 
program flash memory, or execute code before target hardware 
is available. The SuperTAP supports external bus masters in 
multi-processor target systems. You can also use the SuperTAP 
and MWX-ICE in DPI-only mode to debug rack-mounted 
hardware or for field troubleshooting. 

The SuperTAP system integration tool is one member of 
Applied's Design, Test, and Debug tool-set for MPC860 
developers. Other members of this family include: 

□ CodeTEST™ software testing and verification tools let you 
optimize your software's performance and ensure quality 
and rehability in your finished product. 

□ NetROM^ universal target commimications tool transforms 
your target into an easily accessible network node and 
provides a high-speed Ethernet connection between target 
and host. 

□ VSP-TAP™ lets you execute real product software against a 
model of your ASIC and to stimulate the ASIC design with 
real-world data. VSP-TAP works in concert with Viewlogic's 
modeling and simulation tools. 

□ CodeTAP® application development and debug tool 
combines full processor and target visibility with integrated 
support for for multiple debuggers including MWX-ICE and 
Wind Riveras Cross-wind. 

Contact Applied Microsystems for detailed information about 
these tools. 


Product overview 
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Emulator, BDM, and logic analyzer in one tool 

SuperTAP provides a high-quality yet cost-effective approach 
to developing and debugging Motorola MPC860 family 
embedded processor systems. Highly versatile, SuperTAP is an 
emulator, BDM, and logic analyzer in one tool. 

SuperTAP physically replaces the target system's embedded 
processor, then communicates through an Ethernet or high¬ 
speed serial link to MWX-ICE C/C++ source-level debugger. 

Uses no target resources 

Unlike ROM monitors, SuperTAP uses no target resources like 
I/O, memory, or serial ports. Unlike other emulators, 
SuperTAP does not install a monitor in target memory or make 
use of any target resources. SuperTAP does not even require a 
fully functional target, as is common with prototype hardware. 

Non-Stop emulation (NSE) 

NSE™ lets the target system continue to run even when you 
are defining events or uploading trace. This is made possible by 
the SuperTAFs dual-processor architecture. NSE can be 
particularly useful for targets that need to service interrupts 
on demand. 

Debug and track execution of cache-based code 

A large part of the impressive performance of the MPC860 
comes from its two large code and data caches. If you turn them 
off to debug the software your product may no longer function. 
You need to debug in an environment that closely matches the 
way the real product will operate. 

SuperTAP solves the problem with its technology for tracking 
code executed in cache. Now you can debug with the caches 
enabled to enjoy a more reahstic target debug environment. 

isolate complex software and hardware bugs 

Most software bugs are caused by data corruption (stack and 
data pointers becoming corrupt) and program misdirection 
(jumping to the wrong address). Or, the software may run 
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correctly but the target hardware does not respond as it should. 
SuperTAP addresses these problems quickly and efficiently, 
providing: 

□ Real-time emulation with an easy to use multi-windowed C/ 
C++ source-level debugger supporting the popular PowerPC 
compilers 

□ A multi-thread event system which allows tracking and 
detecting the state of the program as well as the processor 

□ 64Kby 128 bits of bus cycle trace history monitors 160 
signals and provides raw bus cycle, assembly, and C/C++ 
soxirce-level display modes 

□ 1, 4, or SMB of overlay memory to hard code, replace, or 
extend target memory 

□ Data access breakpoints in RAM or ROM 

□ Execution breakpoints in RAM or ROM 

□ Trigger input/output capabiUty for linking together multiple 
instruments 

Configure complex integrated peripherals 

Configuring the MPC860 peripherals can be a real challenge. 
The processor data book holds 23 chapters and over 1300 
pages. SuperTAPs MWX-ICE CPU Browser simplifies 
developing and debugging device drivers by providing: 

□ A description of the function of each bit of each register 

□ Pulldown menus with the possible status for each bit 

□ The resulting hexadecimal register value for a particular 
config^ation 

Accelerate your firmware development 

In isolation mode, SuperTAP can be operated stand-alone with 
out a being plugged into a target. With your code loaded into 
overlay memory, isolation mode lets you begin debugging your 
program before target hardware is available. 
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Troubleshoot prototype hardware 

You can verify the design of your hardware and quickly isolate 
manufacturing defects using built-in diagnostic test routines 
and scope loops provided by SuperTAP. Combined with an 
oscilloscope, SuperTAP can quickly isolate manufactoring 
errors in target hardware. 

Monitor target conditions 

SuperTAP monitors and reports target conditions such as: 

□ Processor clock frequency 

□ Target Vcc 

□ Bus error 

□ Reset asserted 

Reai-time visibiiity into your RTOS-based system 

SuperTAP helps you debug both before and after your kernel is 
working on your target. Applied's RTOS-Ldnk option provides 
several broad categories of support, including: 

□ Real-time insight to help develop your Board Support 
Package (BSP) 

□ A real-time tool that let's you debug your kernel 
initialization code 

□ Real-time trace of RTOS activity 

□ Display of individual task context and other system 
structures 

□ Task-quaUfied breakpoints and stack overflow detection 

□ Task profiling support 

□ System-level OS support to debug your Interrupt Service 
Routines 

The benefit of integrated RTOS support is a substantial 
reduction in the time required to debug and optimize your 
application as it nms in your target. 

The event system is specifically designed to help isolate 
problems in multi-threaded software systems found in kernel 
applications. The system is organized in a four-state-by-four- 
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Product overview 


group structure. Each group can be applied to a software 
thread and the four states can be used to isolate deeply nested 
bugs. 

Stop-in-target mode permits a single target execution thread to 
be halted while maintaining additional program threads in 
target. You can determine how frequently the emulator 
interrupts the target operation and the maximum time it can 
spend out of target before restoring the un-halted threads. The 
emulator can interrupt the current operations, service its 
interrupts, restore the original bus state, and resume the 
original operations. 

Compatibility with your tools and hosts 

Host support includes: 

□ Sun 4 (Sun OS 4.1 and above) 

□ PC (Windows 95 or WinNT) 

□ HP9000(HPUX9.0) 

Compiler support for all C/C+4- compilers generating ELF/ 
DWARF version 1.03 or ELF/stabs including: 

□ GNU (C/C++) 

□ DIAB data (C/C++) 

□ Greenhills (C) 

□ MRKC) 

□ Metaware (C/C++) 

SuperTAP used with Applied's RTOS-Link provides support for 
WindRiver and ISI real-time kernels. 

Non-intrusive performance analysis 

SuperTAPs timestamp capability greatly aids in viewing 
system activity and finding code bottlenecks. 

For the most powerful software measurements, team 
SuperTAP with Applied's CodeTEST software verification and 
test tools. CodeTEST provides detailed Performance Analysis, 
Code Coverage Analysis, Memory Allocation Analysis, and 
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extended Source Trace Analysis. For details, request a 
CodeTEST specification sheet or view the information on 
Applied’s web site (http://www.amc.com). 

Innovative target connection support 

The MPC860 adapter and connector support includes: 

□ EGA to PGA connector 

□ Logic Analyzer adapter 

□ Mirror adapter (leaves the processor on card) 

□ Rotation adapters (to facihtate target connection) 

□ Motorola ADS 8XX header adapters (leaves ZIF socket on 
card) 

Electrical characteristics mimic the CPU 

With its fully isolated probe-tip, the SuperTAP behaves 
electrically as close to the emulated microprocessor as is 
possible with today's technology. Zero-delay buffering ensures 
the most accurate emulation. 
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MWX-ICE Debugger for SuperTAP 

MWX-ICE is a function rich, Sun 4, HP 9000/700, or PC-hosted, 
C/C++ source and assembly-level debugger, developed solely 
for debugging embedded applications. MWX-ICE's multiple 
windows, pull-down and pop-up menus, and point-and-click 
ease of use provide a fast, interactive debugging environment. 

MWX-ICE gives you complete control over SuperTAP 
functions: you can selectively start and stop execution, view 
program execution trace with source disassembly, and display 
and modify CPU registers and memory. 


Debugger features 

MWX-ICE features include: 

□ Point-and-click encapsulation of the debugger language via 
command buttons and “notebooks” 

□ Diab data, GNU, Greenhills, and Metaware compiler 
support 

□ Full support of SuperTAP hardware including Trace, Event, 
and Overlay 

□ Powerful breakpoint conditions/actions 

□ C, C++, assembler expression evaluation 

□ Versatile and complete macro language 

□ Accepts batch mode command files 

Easy to use interface 

The MWX-ICE debu^er is a “windowed” user interface. 
Commands are usually executed either of two ways: by t 3 ^ing 
the command in a Command window, or by cbcking a button 
that activates the command. Also available for command 
execution and data entry are editable debugger Windows and 
Notebooks accessed through pull-down menus. 


MWX-ICE Debugger for SuperTAP 
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Shortens the learning curve 

Users may find the more intuitive buttons easier to use while 
learning the debugger. If a button has a command line 
associated with it, that line will be printed in the Command 
window when the button is clicked. This shortens the learning 
curve for users who may ultimately prefer the speed of the 
command line by providing learning reinforcement with each 
button click. 

Powerful Help system 

MWX-ICE includes an extensive but easy-to-use hypertext 
Help system that saves you time otherwise spent searching 
through manuals. 

Handles symbols in a variety of ways 

S 3 mibols include arrays, structures, static variables, register- 
based, and stack-based variables. Sjnnbols can be displayed or 
changed by name, as declared in your program. You can display 
the t 5 rpe and scope of each symbol, and its value in binary, hex, 
ASCII, or decimal format. You can also display memory 
contents with absolute references or register-relative 
references using the Memory window. 

Data and Inspector windows 

MWX-ICE Data and Inspector windows provide access to high- 
level data structures and dynamic variables, and includes C++ 
object support. You can reference structure members, 
dereference pointers, and apply type overrides. 

The Data window lets you easily monitor and examine data 
(and code) using C and C++ source constructs for a dynamic, 
real-time view of the data structure. 

The Inspector window lets you view complex high-level data 
structures and quickly traverse Unked fists. 
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Powerful macro support 

Easily set up using an MWX-ICE “notebook’', macros allow full 
access to debugger features, source-code, and program 
variables. By using the “button editor” you can attach macros 
to the MWX-ICE user interface. 

Macros can be tied to breakpoints, providing an excellent 
method to patch source-code on the fly, and to create program 
“stubs” for code not yet developed. 

Evaluates C, 0+, assembler expressions 

An expression is a combination of operators and operands. 
MWX-ICE supports C, C++, and Assembler expressions. 

MWX-ICE supports the complete C expression syntax. You can 
call your C functions, with arguments, from a C expression; 
exactly as you do in your code. This can be useful for testing the 
behavior of any newly created functions. 


MWX-ICE Debugger for SuperTAP 
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Using SuperTAP with MWX-iCE 


Configuring the initregs 

The SuperTAP maintains a copy of the values stored in some of 
the processor’s chip-select and pin assignment registers. This 
copy is called the set of initialization registers, or initregs, 
because it is used whenever you resume operation after a 
target-generated or MWX-ICE command-driven processor 
reset. The initregs must match the values that the processor 
chip-select and pin-assignment registers have after you run 
your initiahzation code. When you save or restore the initregs 
without specifying a path and filename, MWX-ICE uses the file 
named ireg&rjc^.dat (where the ocxx is replaced by your 
processor type: 860, 821, and so forth). 

MWX-ICE is shipped with four pre-defined versions of the 
iregsxjrx.dat file located in your 
install jdirectory \ amc \ ST8XX: 

□ iregsjrxx.dat^^ - (default) used with isolation mode or as 
a template to be customized for a specific target 

□ iregs860.dat.amc - used with the Apphed Microsystems 
demonstration board 

□ iregs860.dat.ads - used with the Motorola ADS board 

□ iregs860.dat.all - useful for capturing the values of all the 
configuration registers 



The system default iregsa(ra(;x.dat.def file is located in 
install_directory\amc\ST8XK. The original .def file should 
never be modified. 
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> To use the iregsxx*r*dat*def file for isomode (no target): 

■ Copy the file: 

installjiirectory\amc\STSXK\iregsxxx*datAef to your 
working directory as iregs:rxx.dat. 

> To use the iregs860.dat.amc file for Applied’s 
demonstration board: 

■ Copy the file: 

\amc\ST8XX\iregs860.dat.amc to your 
working directory as iregs860.dat. 

starting the MWX-ICE debugger 

The Evaluation Guide assumes the SuperTAP and debugger 
are installed and the debugger has been connected to the 
emulator, described in Chapter 2 of the MWX-ICE User's 
Manual, 

> To start MWX-ICE: 

■ From Program Mauiager, choose the MWX-ICE 860 icon. 

MWX-ICE debugger starts with the Code and Command 
windows open, shown in Figure 1. 


Using SuperTAP with MWX-ICE 
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Figure 1 MWX-ICE successfully started 


Getting debugger help 

Context-sensitive Help is available for MWX-ICE. For 
information about Applied Microsystems and Applied 
Microsystems products, choose About MWX-ICE from the Help 
menu, or chck the About Apphed Microsystems button on a 
notebook page. 
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stopping emulation (leaving run mode) 

important information at)out leaving run mode 

The SuperTAP emulator operates in one of two modes: run 
mode, when the emulator is executing target code, and pause 
mode, when the emulator is not executing target code. In run 
mode the cursor turns into a “rimning man.” To leave run mode 
at any time and return to pause mode, click the Stop button in 
the tool bar. 

Loading the demonstration code 

Cdemon is the Applied Microsystems standard C/C++ 
demonstration progrsun, providing examples of many code and 
data constructions used by programmers. The demonstration 
program is designed to be used with the SuperTAP and an 
Applied Microsystems demonstrator board. 

Cdemon is composed of four major functions running in main(): 
initialO, stepO, dataO, and nm(). The LEDs on the 
demonstrator board or a Data window monitoring led j)ort can 
be used to see the output of some of the functions. For a 
detailed explanation of the Cdemon demonstration program, 
see Appendix A of this guide. 

‘Include” debugger command files 

An include file is simply a file containing debugger commands 
that will be executed when the file is loaded by the debugger. 
The suppHed include file, cdemon.inc, maps overlay then loads 
the Cdemon absolute file firom the demo subdirectory. 



Stop button 
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> To load the demonstration file: 

1. From the Displays menu, choose Code. 

2. From the File menu, choose Include Commands. 

3. Using the file browser, navigate to the 
imtalljiir\Bmc\ST8XX\demo directory. 

4. Select cdemon.inc, then choose OK 

Observe the Command window for SuperTAP status and ex¬ 
ecuted commands. After downloading the file, the Code win¬ 
dow displays the source module, shown in Figure 2. 


( Code 




Initializing _ Hodulc: CDEMOH File: cdcmon-cc _ 'i 

1 /» cdenon for HPC868 uersion 1.B */ \ 

2 /. I 

3 ** File: cdenon.cc I 

4 »» Description: Universal Sales Demon Blinking LED Demonstration Program^ 


The purpose of this program is to provide a demonstration 
sample to use with various types of debuggers. This program 
exercises the LEDs of the applied Hicrosystens Sales Demons and 
the Elevator Control Demons. 

This nodule contains the main application procedure and is the 
first code executed after the startup procedure. All other 
nodules and functions are called from this main procedure. 


Copyright (c) 1994 Applied Hicrosystens Corporation 
All Rights Reserved 


Figure 2 Cdemon demonstration file successfully loaded 
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Viewing source-level and assembly code simultaneously 

The Windows menu “Copy This Window** button lets you open 
multiple instances of a window. Below, you open two Code 
windows; one window displaying source-level and the other 
displaying interleaved source-level and assembly. The two 
windows stay synchronized during all emulator operations 
such as single-stepping, running to breakpoints, and restarting 
the code. 

To open another Code window and display assembly: 

1. Make the Code window active. 

2. From Displays menu, choose Copy This Window. 

3. In Mode button for the new Code window, choose Assembly. 

You can arrange the two Code windows for the best viewing, 
shown stacked in Figure 3. 


: MWXST8B0I(omb2] - Code 


wiHm 


f Con 


HPCe68 Nodule: CDEHON File: cdenon.cc 


56 

57 


nain(int, char 
{ 


s 

58 



59 

if ( which 

1 

68 

eleu_n< 


61 


$ 

62 

initialO; 

5 

63 

stepO; 

\ 

64 

dataO; 

5 

65 

run(); 


66 

return 8; 




►[]) /» Progran Starts Here »/ 


/• Initialize Variables */ 

/• Single Step Loop »/ 

/• Data Hanipulation Demo, Card Gane •/ 
/• Run Blinking Leds •/ 



I ;||MWXST860(t(Mli2] • Code 
I Copmand HPC860 




Nodule: CDEHON File: cdenon.cc 


_ii 


56 

57 




nainCint, char •[]) 
{ 


FfF02098 : 9Ji21fff8 
ffF82B9c: 7c88e2a6 
FFfB20a0: 9881 OOOc 

58 

59 if ( «fhich_deno ) 
fff828a4: 818d8B18 
FffB28a8: 2C0C8B8B 
Fff828ac: 41820888 


stwi 

nfspr 

stw 


IHZ 

cnpwi 

beq 


/* Progran Starts Here */ 


r1,-0x0808(r1) 

r8,lr 

r8,89(888c(r1) 


r12,-8x7ff8(r13) 

r12,8xB 

.+0X8 


Figure 3 Displaying source-level and assembly code 
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Super TAP configuration information 

When starting a debug session you should take a quick look at 
the state of the debugger and emulator. This is particularly 
true if someone else has used the emulator between your 
sessions. You can easily examine or modify the emulator's state 
by using the Emulator Configuration window. 

If you ever need to call Customer Support for assistance, the 
information displayed with the following commands and 
windows can help them resolve your call. 

> To display operating environment information: 

1. In the Enter Command box of the Command window, enter: 
stat all 

This hsts details about the current operating environment. 

2. From the File menu of the View status window, choose Close 
Window, being careful not to inadvertently select Exit 
Debugger. 

> To display emulator component and revision 
information: 

■ In the Enter Command box of the Command window, enter: 
hwconfig 

This hsts emulator component, firmware, and software revi¬ 
sion levels and installed options. 

> To view the emulator configuration 

■ From the Displays menu, choose Emulator Configuration. 
The Emulator Configuration window appears. 

You can use the Emulator Configuration window, shown in 
Figure 4, to view and modify the options that control the 
state of the debugger and emulator: 
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Figure 4 Emulator Configuration window 

Connections The Connections button brings up the 
Connections window. Use this window to define and connect to 
emulators. 

Execution The Execution button opens the Execution 
configuration dialog box. Use this dialog box to set the 
emulator execution options. 

Trace The Trace button opens the Trace configuration dialog 
box. Use this dialog box to set emulator trace collection and 
display options. 

Memory The Memory button opens the Memory 
configuration dialog box. Use this dialog box to set memory 
access attributes. 

Event The Event button opens the Event configuration 
dialog box. Use this dialog box to set the emulator event system 
options. 
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Pile Handling The File Handling button opens the File 
Handling configuration dialog box. Use this dialog box to 
specify the upload and download format for non-lEEE-695 
object files, and to other download options. 

Debugger Internal The Debu^er Internal button opens 
the Debugger Internal configiuration dialog box. Use this dialog 
box to set input and output radix and other debugger options. 
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Chapter 2 

Examples 


This chapter provides examples demonstrating the Applied 
Microsystems SuperTAP system integration tool with 
MWX-ICE debugger. You must complete all of Chapter 1 before 
doing any of the examples. 

The examples are organized into functional groups, with each 
group prefaced by a brief discussion of the function: 

□ Accelerate the debug of prototype hardware 

□ Accelerate firmware development using overlay 

□ Intuitive breakpoints on code and data 

□ Controlling code execution - breakpoints and event system 

□ Capturing and viewing trace history 

□ Examples of other time-saving features 

Running the examples 

How long does it take? 

It takes approximately two hours to complete all the examples. 

Run the examples that most interest you 

All the examples can be run independent of each other. 
Because the examples are not interdependent, you can choose 
and run, in any order, the examples that most interest you. 

Complete all steps within an example 

You must complete each step within an example. The final 
steps of an example return settings to their original value, so 
you can do the examples in any order. 


Examples 
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Accelerate the debug of prototype hardware 

Crash proof debugging and testing 

SuperTAP incorporates a dual-processor architecture where an 
emulation processor replaces the target processor while a 
second control processor handles communications with the 
debugger and monitors the target processor activity. This 
insures that a target processor crash will not cause the 
emulator to “hangf. 

Built-in scope loops and memory diagnostics 

A full suite of scope loops and memory diagnostic programs 
included with the debugger let you verify the design of your 
hardware and quickly isolate manufacturing defects. 




Some companies use the diagnostic routines as part of their 
regression tests.The tests can be left running overnight to 
locate thermal problems. Also, the tests can run concurrent 
with the trace and event systems, useful for locating subtle 
bugs. 

Monitor target conditions 

SuperTAP monitors and reports target conditions such as: 

□ Processor clock frequency 

□ Target Vcc 

□ Bus error 

□ Reset asserted 


Target monitoring features can isolate conditions that cause 
other emulators to hang. This ability helps in situations where 
you are debugging new and unproven hardware. 

In addition, the power monitoring circuitry provides electrical 
protection to the target and emulator, lessening the potential 
for damage and reducing the risk of repairs and lost debugging 
time. 
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Example 1 - Crash-proof tool including trace history 

Target system and processor initialization routines are often 
the most difficult code to debug, particularly on prototype 
targets. SuperTAP lets you execute to a breakpoint set in a 
target power-up or reset sequence, while collecting trace 
history, without hanging the debugger. This lets you debug 
startup and initialization code. To illustrate this, you: 

□ Enter Dynamic Rxm mode. 

□ Set a breakpoint at the address of the Cdemon startup 
routine _start (a few instructions after the RESET vector 
fetch. 

□ Issue a reset command to reset the CPU. If the emulator is 
plugged into an Applied Microsystems demonstrator board, 
you can use the demonstrator board RESET button to reset 
the CPU. 

This same procedure also works for a full target power-up 
sequence; you can actually cycle target power and still hit a 
breakpoint. 

This example is written for the Applied Microsystems 
demonstrator board. If you are using your own target and code, 
you can modify the breakpoint address to the startup routine 
used in your code. 

> To restart the Cdemon program and enter dynamic run 
mode: 

1. From the File menu, choose Restart: 

2. In the Enter Command box, enter: 
drun 

Observe the LED on the demonstrator board incrementing. 

> To set an instruction breakpoint at _start: 

■ In the Enter Command box, enter: 

bi _start 
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>■ To run to the breakpoint: 

■ In the Enter Command box, enter 
reset 

-OR- 

If the emulator is plugged into an Applied Microsystems 
demonstrator board, press then release the RESET button 
located on the edge of the demonstrator board. 

SuperTAP breaks emulation at the beginning of the startup 
procedure _start, shown in Figure 5. 

> To clear the instruction breakpoint at _start: 

■ In the Enter Command box, enter: 
clear 1 





fff00164 
fffOOIOS 
fffoeioc 
fff00116 
fff60114 
fffOOIIS 



b 

INULD 

IHULD 

INULD 

INULD 

INULD 


liil 



Rgure 5 Breakpoint at START (Assembly Code window) 
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Example 2 - Scope loops and peek/poke trace 

Built in scope loops, cyclic redundancy checks (CRC-16), and 
memory diagnostic programs save you from writing your own 
routines to test memory or to stimulate memory for use with 
other tools, such as an oscilloscope. When running a scope loop 
or memory diagnostic, the read and write cycles are captured 
in trace memory (peek/poke trace). This information can be 
used to diagnose malfunctioning target memory or I/O. 

Diagnostics 2 through 7 are used to perform reads or writes of 
selected memory. 

> To perform a continuous read 

1. In the Enter Command box, enter: 
diag 2,0xa0000000.•0xa0000400 

2. From the toolbar, choose Stop to stop the test. 

Diagnostic numbers 0 and 1 perform simple and complex 
diagnostics on the selected memory. 

> To perform a complex memory test 

1. In the Enter Command box, enter: 
diag 0,0xa0000000. •03ca0000400 

2. From the toolbar, choose Stop to stop the test. 

Use the crc command with a range argument to perform a 
CRC-16 of the specified range. The command will return a hex 
value for the CRC. 

> To perform a cyclic redundancy check 

■ In the Enter Command box, enter: 
crc 0x0xa0000000«•0xa0000400 
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Example 3 - Benefits of event system qualified trace 

Quite often there will be only a few cycles of interest out of the 
milhons of cycles executed in a real-time run of the code. There 
are two ways of deaKng with this: 

1. Capturing, in real-time, a trace of only the cycles of interest. 
This is a quaHfied trace. 

2. Post-processing (filtering out unwanted cycles) a large and 
expensive trace RAM buffer full of all executed and pre¬ 
fetched instructions. 

The first is by far a quicker and more accurate method than the 
second. With SuperTAFs four-level event system architecture 
and trace control actions, you can capture a qualified trace 
based on a complex set of conditions, including program events, 
target hardware events, and the CPU bus state. 

The example demonstrates this abihty by capturing only the 
first 10 memory write cycles directed to the in-memory 
representation of the demonstrator board LEDs. 

> To restart the Cdemon program: 

■ From the File menu, choose Restart. 

> To configure the trace system: 

1. From the Displays menu, choose Emulator Configuration. 

2. In the Emulator Configuration window, choose Trace. 

3. In the Trace configuration window, choose: 

Collection State at RuniDon't Accumulate at Run 

This keeps trace capture turned off xmless enabled by the 
event system. 

4. In the Trace configuration window, choose: 

Clear Buffer at Run:Discard Current Contents 

This clears the trace buffer when the emulator enters run 
mode. 
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5. In the Trace configuration window, choose: 

Collection Qualification:Bus Cycles 
This configures trace for bus qualified capture. 

6. In the Trace configuration window, choose Apply to accept 
the values, then close the window. 

> To configure the event system: 

1. In the Emulator Config window, choose Event. 

2. In the Event configuration window, choose: 

Counter # 1: Initial ValueReset to Zero at Run 
This resets the counter to zero when entering run mode. 

3. In the Event configuration window, choose Apply to accept 
the values, then close the window. 

4. In the Enter Command box, enter: 

when addr==&led_port && status==wr then trone,ctrlinc 

Note: led j>ort is the symbol for in-memory representation of 
the LEDs (0x80000000). The & tells the event system to look 
at the address of led^ort. 

5. In the Enter Command box, enter: 
when ctrl==10 then break 

> To run the target code: 

■ From the toolbar, choose Go. 

SuperTAP breaks emulation after tracing the first 10 writes 
to the in-memory representation of the demonstrator board 
LEDs. 

> To display trace: 

■ From the Displays menu, choose Emulator Trace. 

Only the 10 write cycles are in trace, shown in Figure 6. 
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>■ To clear the event system: 

■ In the Enter Command box, enter: 

whenclr all 
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Figure 6 Emulator Trace window - qualified trace capture of the first 10 writes 
to the demonstrator board LEDs 
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Example 4 - Isolate complex bugs with the event system 



Sometimes rxmning to a basic breakpoint and examining trace 
history does not provide information specific enough to debug 
your target’s code or hardware. You may also want the 
emulator to perform some action other than stopping code 
execution when the conditions become true. You may need to 
trigger an oscilloscope after a complex set of CPU bus cycle 
conditions become true; for example, the fifth write that a 
specific subroutine makes to a certain memory location. At 
other times you may want to trace only specific types of bus 
cycle information under certain conditions. 

The event system supplies the mechanism to define conditions 
and take actions. This mechanism allows the emulator to 
perform various actions based on conditions of complexity far 
surpassing that of simple breakpoints. 

The event system is used primarily for debugging nested or 
sequential problems. By defining a logical sequence of events, 
you can locate a hard to find bug that may exist only under a 
particular set of circumstances. 

The event system is implemented with emulator hardware and 
can be used in both RAM and ROM regions. 

Monitor complex sets of conditions 

SuperTAP event system comparators comprise 80 bits of 
information, including address, data, status, and external 
signals. The comparators can use “don't-care” masks and can 
cover ranges. Using these comparators, you can monitor a 
complex set of conditions, including program events, target 
hardware events, and the CPU bus state. 

Do more than just break 

When the event system conditions have been met, SuperTAP 
can perform a variety of actions including: 

□ Break emulation asynchronously or synchronously 
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□ Trace one or many CPU bus cycles 

□ Set/increment/reset memory or register 

□ Set or reset event system flags 

□ Switch between event system groups 

□ Enable or disable timestamp 

□ Call a user specified function 

□ Generate a trigger output to an external instrument 


The example is a simple case requiring more than a breakpoint 
You set up the event system so that only the cycles within a 
certain function outledO are traced. To do this, you define two 
events to start trace capture when outledO is entered, and 
stops trace capture when outledO transfers program execution. 

> To restart the Cdemon program: 

■ From the File menu, choose Restart. 

> To set up initial trace conditions: 

1. From the Displays menu, choose Emulator Configuration. 

2. In the Emulator Configuration window, choose Trace. 

3. In the Trace configuration window, choose: 

Collection State at Run:Don't Accuimilate at Run 

This keeps trace capture turned off imless enabled by the 
event system. 

4. In the Trace configuration window, choose: 

Clear Buffer at Run:Discard Current Contents 

This clears the trace buffer when the emulator enters run 
mode. 

5. In the Trace configuration window, choose: 

Collection Qualification:Cycles needed for Disassenibly 

This configures trace to capture information for disassem¬ 
bly. 
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6. In the Trace configuration window, choose Apply to accept 
the values, then minimize the window. 

> To set up event statements to start and stop tracing: 

1. In the Enter Command box, enter: 
ps outled 

From the output of the printsymbols (ps) command, you 
can easily determine the address range of the function out- 
ledO. 


i MWXST860[lomb2] - Command 


|> ps outled 

OUTLED\outled 



: Global Function returning void. 
Address » FFFe23Be to FFFe24CC 
Arguments: (uoid) 



Figure? Printsymbols output for outled() 

2. In the Enter Command box, enter: 
when addr==outled then tron 

This event statement turns tracing on at the start address of 
the function outledO. Notice a View window is opened when 
you enter the command. 

3. In the Enter Command box of the Command window, enter: 
when addrs:=0xf£f024cc then tro££,break 

This turns tracing off at the end of the function outledO, then 
breaks emulation. (Note: In this case the troff is not really 
necessary since trace capture always stops when a break oc¬ 
curs. Troff is most useful when you want to capture a trace 
of something while continuing to emulate.) 

> To run until the break condition is met: 

■ From the toolbar, choose Go. 
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> To view trace in the Emulator Trace window: 

1. From the Displays menu, choose Emulator Trace. 

This opens the Emulator Trace window with the default dis¬ 
play mode (Raw Display) active. 

2. In the Display Format box, select the Assembly and Source 
checkboxes. 

Only the source lines and their associated assembly code for 
the function outledO are displayed in the trace buffer win¬ 
dow, showm in Figure 8. 

> To clear the event system: 

■ In the Enter Command box, enter: 
whenclr all 
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Accelerate firmware development using overlay memory 

Description 



Real-time code execution vehicle 

Overlay provides stable substitute memory into which you can 
load your code and data. Using overlay, you can begin 
debugging your code before target memory hardware is 
operational. Overlay memory accelerates the code debug, re¬ 
make, and test cycle. Using the high-speed net connection (5 
MB/sec) you can quickly download your fixed code into overlay 
rather than burn a new EEPROM. 

SuperTAP can be equipped with an optional 1 MB, 2 MB, or 4 
MB of overlay memory (zero wait states to 25 MHz, 1 wait state 
to 40 MHz). 

Overlay memory can be allocated in minimum 128Kb segments 
(a ViSiSb granularity). Overlay supports 8,16, or 32 bit ports 
and DMA accesses by external bus masters. 

Copy memory contents between the target and overlay 

SuperTAP lets you easily copy the contents of target memory 
into overlay memory or fi:om overlay into target memory. You 
can use this capability when you need to copy the contents of 
your target ROM (or PROM) into overlay memory, to avoid 
burning a new ROM. Also, copying the contents of target ROM 
into overlay lets you set software breakpoints within ROM 
memory space. 
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Example 5 - Using overlay memory 

To use overlay memory you assign (map) it to address ranges 
and access types (read/write or read-only). Overlay memory 
can replace target memory or substitute for memory that does 
not exist in the target. 

In this example you view the overlay memory map set up by the 
cdemon.inc include file. 

> To view the current overlay memory map: 

1. In the Enter Command box of the Command window, enter: 

zoap 

Observe the current overlay map, shown in Figure 9. All 
three ranges of mapped overlay were assigned Read/Write 
access and there is 256Kb of overlay still available for map¬ 
ping. 

2. Close or minimize the View Memory Map window. 





R^nge 

Type 
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80000ee0o.80eiFFFF 

RU 

0 
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RU 


UURILABLE: 3328K of 

4096K 

S 





Figure 9 Overlay memory mapped by cdemon.inc include file 
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Controlling code execution 

When debugging code, the abiUty to control code execution is 
essential. SuperTAFs breakpoints and event system let you: 

□ Stop asynchronously at any time 

□ Execute code until reaching a particular location or 
satisfying a set of conditions 

□ Single step lines of source or assembly code 

□ Step into or over function calls 

To provide this abiHty SuperTAP supports four t 5 rpes of 
breakpoints: 

□ As 3 mchronous 

□ Hardware execution and access 

□ Software execution 

□ External 

Do more than just break 

When breakpoint conditions are met, SuperTAP can perform 
any of the following actions: 

□ Stop emulation (break) 

□ Execute a C expression 

□ Log the value of an expression in a file 

□ Execute a debugger macro 


Description 


Assmchronous breaking capability lets you stop code 
execution at any time by clicking the MWX-ICE Stop button. 
This abihty can help in situations where you need to stop a 
program that is executing incorrectly and has bypassed a 
breakpoint you set. 
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Hardware execution and access breakpoints use the 
SuperTAFs hardware and do not consume any target 
resources. When a memory access occurs that matches the 
breakpoint condition, microprocessor execution stops. 
Hardware execution and access breakpoints can be set over 
target RAM or ROM. 

Software breakpoints replace the instructions in the target 
program with a special opcode that forces a specific behavior in 
the microprocessor. When the breakpoint occurs, SuperTAP 
halts execution and places the original instruction back into 
memory. 

External breakpoints allow an external trigger-in signal 
from the target or from a piece of test equipment, such as a 
logic analyzer, to cause the SuperTAP to “break’^ out of 
emulation. Or, the SuperTAP can generate a trigger-out signal 
to trigger a logic analyzer or storage scope. 

SuperTAP provides one BNC trigger input and one BNC 
trigger output pin to support both types of external 
breakpoints. 
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Example 6 - Intuitive breakpoints on code and data 

Software breakpoints must be located in RAM, so that the 
special opcode may be written to target memory. This poses no 
problem, since SuperTAFs overlay memory can easily be used 
for setting breakpoints where no target RAM exists. 

MWX-ICE offers a variety of methods that make setting and 
clearing breakpoints easy. In this example, you sample the 
various methods including: 

□ Using the Execution Control notebook 

□ Choosing the BreakI button with a source line selected 

□ Dragging the BreakI button to a source line 

□ Using the Breakpoints window 


> To restart the Cdemon program: 

■ From the File menu, choose Restart. 

> To set a permanent breakpoint using a notebook: 

1. From the Notebooks menu, choose Execution Control. 

2. From the Execution Control menu, choose Set and clear 
breakpoints. 

3. In the Break page Start Address box, type: 
main 

4. Choose the Set Break button, to set the breakpoint. 

Notice that “Breakinstruction main’' is echoed in the Com¬ 
mand window. By observing and remembering the com¬ 
mands generated while using notebooks and buttons, you 
can quickly start using the command line interface. 
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5. From the toolbar, choose the Go button to run to the 
breakpoint. 

Notice that the Code window box indicating the current exe¬ 
cution line has moved to the beginning of main(). Also notice 
the breakpoint icon (a small stop sign) in the left side of the 
current execution Une, shown in Figure 10. 

6. In the Execution Control notebook, choose Close to close the 
window. 


, MWXST860Ilomb2| - Code 


Connand 


HPC86Q Module: CDEMON File: cdenon.cc 
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55 

int 


56 

main(int, char «[]) 

57 



58 



59 


if ( uhich^demo 

60 


eleu^inainO 

61 



62 


initialO; 

63 


StepO; 

64 


dataO; 

65 


run(); 

66 


return 0; 

67 

> 



Main C Routine 


/* Program Starts Here */ 


/* Initialize Uariables «/ 
i* Single Step Loop */ 

/« Data Manipulation Deno, Card Game «/; 
/« Run Blinking Leds 



Figure 10 Breakpoint at beginning of mainQ 

V To set a permanent breakpoint using the BreakI button 
and a selected line: 

1. In the Source Code window, select the source line containing 
the stepO function by double-clicking an3rwhere in that line. 

When selected, there will be at least one character of the line 
highlighted. 
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2. Choose the Breakl button 



to set the breakpoint. 


Notice the breakpoint icon displayed to the left of the stepO 
source line. 

3. From the toolbar, choose Go to rim to the breakpoint. 


> To set a permanent breakpoint dragging the Breakl 
button to a source line: 

1. In the Source Code window, click and hold the Breakl button 
and drag the breakpoint icon to the source line containing 
the dataO function. 

Notice the breakpoint icon displayed to the left of the dataO 
source line. 

2. From the toolbar, choose Go to nm to the breakpoint. 


To run to a specific source line (temporary breakpoint): 

1. In the Source Code window, select the source line containing 
the run() function by double-cUcking anywhere in that line. 

2. From the toolbar, choose the GoUntil button (man running 
to stop sign) to run to the run() function. 

To view permanent breakpoints: 

■ From the Displays menu, choose Breakpoints. 

Notice the three breakpoints displayed in the window; the 
top one set at main() using the Execution Control notebook, 
the second one set at stepO by choosing the Breakl button 
with a line selected, and the third set at dataO by dragging 
the Breakl button. The Breakpoints window is shown in Fig¬ 
ure 11. 
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Figure 11 Displaying infotmation about a breakpoint 


> To clear all permanent breakpoints: 

1. In the Enter Command box of the Command window, enter: 
clear 

2. Close the Breakpoints window. 
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Example 7 - Hardware execution and access breakpoints 

Hardware execution breakpoints use the SuperTAPs hardware 
and do not consume any target resources. Unlike software 
execution breakpoints, which must be set in RAM, hardware 
execution breakpoints can be set over RAM or ROM. Using 
either method, execution stops when the processor executes the 
instruction. 

Access breakpoints are useful for detecting errant accesses to 
memory locations. For example, you may want to break 
emulation if your code attempts to write over a constant 
pointer. 

In the example, you set a write access breakpoint (bw) at the 
memory address i&led_port is 0x80000000) of the in-memory 
representation of the demonstrator board LEDs. Read access 
(br) and read-or-write access (ba) breakpoints are set 
similarly. 

> To restart the Cdemon program: 

■ From the File menu, choose Restart. 

> To set a write access breakpoint: 

1. In the Enter Command box, enter: 
bw &led_port 

2. From the toolbar, choose Go to run to the breakpoint. 

SuperTAP breaks emulation at the initialization routine’s 
write to 0x8000000 (led j)ort's first address), shown in Fig- 
me 12. 
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k Command 


|> Restart 

I Note: in startup routine. Enter STEP to go to nain. 


P go 

i Break 4 1 on write to 


nodule TEXT_2 (current instruction address = FFF84F48)[^ 



Figure 12 Break on initialization (write) of ledjort 

3. From the toolbar, choose Go to run to the breakpoint. 

SuperTAP breaks emulation in the outledO function at the 
write to the in-memory representation of the demonstrator 
board LEDs. 

> To monitor the variable ledjfort: 

1. From the Displays menu, choose Data. 

2. In the Data window Expression field, enter: 
led_port 

3. From the Data window View menu, choose Show (char*) as 
String. 

4. From the toolbar, choose Go, to run to the breakpoint a few 
times while you watch the LEDs on the demonstrator board 
increment or the variable ledj>ort increment in the Data 
window. 

5. Close the Data window. 

> To clear the write access breakpoint: 

■ In the Enter Command box, enter: 
clear 1 
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Capturing and viewing trace history 

With trace history you can capture and record, in real-time, the 
execution history of the processor as SuperTAP executes the 
target program. Using trace history, you can verify the correct 
performance of the software and find errors that may occur in 
the program's execution. Trace lets you move from the 
environment of %unt-and-peck” to one where real evidence is 
easily captured and displayed, helping you isolate and correct 
the bug. 

The intelligent trace disassembly feature - an industry first - 
dramatically increases productivity by displaying instructions 
correlated with register values and bus cycles. 


Description 

Trace history offers 32Kxl28 bits of information including all 
active MPC860 signals and 32 bits of timestamp information. 
You can display raw bus cycles, full source-level, assembly- 
level, or mixed somce and assembly-level trace information 
with MWX-ICE’s four trace display modes. 

Capturing ''qualified” trace versus filtering continuous trace 

Quite often there will be only a few cycles of interest out of the 
millions of cycles executed in a real-time nm of the code. There 
are two ways of dealing with this: 

1. Capturing, in real-time, a trace of only the cycles of interest. 
This is a qualified trace. 

2. Post-processing (filtering out unwanted cycles) a large and 
expensive trace RAM buffer full of all executed and pre¬ 
fetched instructions. 

The first is by far a quicker and more accurate method than the 
second. 



Capturing and viewing trace history 


49 




With a four-level event system architecture and “trace one 
cycle” action, SuperTAP lets you capture a qualified trace based 
on a complex set of conditions, including program events, 
target hardware events, and the CPU bus state. 

Execute and trace target power-up or reset sequences 

You can a execute a target power-up or reset sequence while 
collecting trace history, without hanging the debxjgger. With 
this you can more easily debug startup code. 

Dynamic trace display 

SuperTAP allows you to view and upload trace history without 
stopping or even pausing emulation. This means you can view 
your program's activity without disturbing its real-time 
operation. Example 9 in the Event System section of this guide 
demonstrates this abiUty. 

Timestamp 

Timestamp information provides an accurate measurement of 
elapsed time between cycles displayed in trace. SuperTAP 
provides timestamp information to 40 nsec. 

Saving trace history in a file 

The log command lets you easily store trace history in a file by 
naming a Journal file in an MWX-ICE notebook then simply 
displaying trace. You can even log trace to a file without 
stopping emulation. 

After trace is saved, you can edit the file to add comments for 
future reference. For example, comments may be added to aid 
in documenting failure conditions. 


Need help? Call Customer Support at 1-800-ASK-4AMC for assistance. 





Example 8 



Intelligent trace disassembly 

The “intelligent” trace disassembler boosts productivity by 
providing insight into the operation of the processor. The 
disassembler tracks the state of processor registers, letting you 
easily see how data is passed during code execution. 

> To restart the Cdemon program: 

■ From the File menu, choose Restart. 

> To set up initial trace conditions: 

1. From the Displays menu, choose Emulator Configuration. 

2. In the Emulator Configuration window, choose Trace. 

3. In the Trace configuration window, choose: 

Collection State at Run:Begin Accumulating at Run 

4. In the Trace configuration window, choose: 

Clear Buffer at RunsDiscard Current Contents 

This clears the trace buffer when the emulator enters run 
mode insuring that all cycles captured in trace are from the 
current code execution. 

5. In the Trace configuration window, choose Apply to accept 
the values, then minimize the window. 

> To execute to the function stepO: 

1. In the Code window, scroll down to the stepO fimction. 

2. Select that line by double-clicking the function stepO. 

3. From the toolbar, choose GoUntil. 

> To view trace in the Emulator Trace window: 

1. From the Displays menu, choose Emulator Trace. 

This opens the Emulator Trace window with the default dis¬ 
play mode (Raw Display) active. Raw trace display includes 
address, data, active processor signals, and timestamp infor- 
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mation. The Frame numbers provide an index of where the 
cycle occurred in execution history, the lowest Frame num¬ 
ber being the most recent instruction executed. 

2. From the View menu, deselect Raw and select Assembly and 
Source. 

The source lines and their associated assembly code for pro¬ 
gram execution to the fimction stepO are displayed, shown in 
Figure 13. The Emulator Trace Action menu provides many 
useful trace utihties that let you easily: 

□ Set breakpoints using trace information 

□ Set the current scope based on trace frame 

□ Search trace for any string patterns 

□ Scroll through the trace buffer 

□ Clear the trace buffer 

□ Change trace display configuration 

□ Change timestamp format and offset base frame 
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Figure 13 Emulator Trace window - mixed source and assent)ly trace 
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Example 9 



Capturing and viewing trace whiie running 

In this example, SuperTAP emulates in d 3 mamic mode; you can 
display trace while still emulating. You capture the run() 
function in trace using the event system, then view the trace in 
raw and disassembled formats. 

To restart the Cdemon program: 

■ From the File menu, choose Restart. 

> To set up the initial trace condition: 

1. From the Displays menu, choose Emulator Configuration. 

2. In the Emulator Configuration window, choose Trace. 

3. In the Trace configuration window, choose: 

Collection State at Run:Don't Accuimilate at Run 

This keeps trace capture turned off unless enabled by the 
event system. 

4. In the Trace configuration window, choose: 

Clear Buffer at Run:Discard Current Contents 

This clears the trace buffer when entering run mode. 

5. In the Trace configuration window, choose: 

Collection Qualification:Cycles needed for Disassembly 

This configures trace for bus qualified capture. 

6. In the Trace configuration window, choose Apply to accept 
the values, then minimize the window. 

> To set up event system: 

1. In the Enter Command box, enter: 
when addr=soutled then tron 
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2. In the Enter Command box, enter: 
when addr==0x£££024c4 then tro££ 

The View Event System window should display the two 
event system statements. 

> To enter dynamic run mode: 

■ In the Enter Command box, enter: 
drun 

> To display a "snapshot” of trace while still running 
target code: 

1. In the Enter Command box, enter: 

drt 

This displays trace history in raw format in the Command 
window. 

2. In the Enter Command box, enter: 
dtb 

This displays trace history in interleaved soiarce and assem¬ 
bly format in the Command window. 

Notice in Figure 14 that the register values on the right are 
matched to the source lines on the left. This is the “intelH- 
genf' trace disassembly feature. 
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Figure 14 Dynamic trace display - disassembled source and assembly 


> To exit dynamic run mode and clear the event system: 

1. In the Enter Command box, enter: 

dstop 

2. In the Enter Command box, enter: 

whenclr all 

This clears all event system statements. 
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Examples of other time-saving features 

Description 

This section contains examples of other useful, time-saving 
features of SuperTAP with MWX-ICE: 

□ Configure, understand, and debug peripheral registers 

□ Displaying high-level data structures 

□ Monitoring and modifying variables dynamically 

□ Displaying and modifying memory 
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Example 10 - Configuring/debugging peripheral registers 

« MWX-ICE includes the CPU Browser™ and Register Browser™ 
L . windows, to save you time you might otherwise spend 

referencing a technical manual for register bit meanings. The 
POR 0 PCMIA Option 0 window, is shown in Figure 15. 

>■ To browse the regfister: 

1. From the Displays menu, choose CPU Browser. 

2. From the CPU Browser Menu, choose PCMIA Interface. 

3. From the CPU Browser window, choose PORO PCMIA 
Option 0. 




»OSO pcncu Opclon 0: OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO tOxOOOOOOOO) 


Error-check value on Apply 
PCHCIA Bank Size: 

I PCHCIA Strobe Hold Time: jp clock cycle 


PCHCIA Strobe Set_up Time: |i clock ^cle F| 
PCHCIA Strobe Length: jpz clock^cycles|^ 
PCHCIA Port Size: | g bits 

PCHCIA Region Select. |pri ni> oiT*«i ciTM nir^^r** 

PCHCIA Slot Identifie; HbBwHBbM 

Attribute memory space 
Brite Protected (Read I/O space 

DBA (normal transfer) 
PCHCIA Valid Bit: DHA last transaction 


I Apply {I Restore Value j | Cancel 


Figure 15 Browsing a register 
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Example 11 - Displaying high-level data structures 

The MWX-ICE Inspector window lets you view complex high- 
level data structures and quickly traverse linked lists. 

> To restart the Cdemon program: 

■ From the File menu, choose Restart. 

> To run to houseO, a function in dataO: 

■ In the Enter Command box, enter: 
g DATA\house 

Emulation breaks at the beginning of houseO, a function 
within dataO. At this point, all of the cards in the blackjack 
game have been dealt. 

> To display the structure players: 

1. From the Displays menu, choose Inspector. 

2. In the Inspect S 3 nnbol or Expression box, enter the following: 
players 

The Inspector window displays a break down of players. You 
can scroll or resize the Inspecting window for the best dis¬ 
play of the structure. 

3. From the Inspector window View menu, choose Show (char*) 
as String. 

4. From the Inspector window, choose S» for player[01]. 

The Inspector window displays a break down of player[01], 
the second element of players. 

In Figure 16, you can see playerl ‘WarF won, having been 
dealt 2 cards for a total of 21 points. 

5. Close the Inspector window. 
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Example 12 - Modifying variables dynamically 



MWX-ICE provides windows for working with program 
variables. 

□ Data window, for monitoring variables. 

□ Inspector window, for viewing and modifying variables. 

□ Register window, for viewing and modifying register-based 
variables. 

In static mode, they are updated only at each single-step, 
breakpoint, or program halt. In dynamic mode, emulation 
periodically pauses then re-starts, updating each window when 
emulation is re-entered. 


> To restart the Cdemon program: 

■ From the File menu, choose Restart. 

> To enter d3miamic run mode: 

■ In the Enter Command box, enter: 
drun 

> To dynamically monitor the variable led_porti 

1. From the Displays menu, choose Data. 

2. In the Data window Expression box, enter the following: 
led__port 

This places the variable led_port in the Data window, shown 
in Figure 17. 
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>- To enter dynamic update mode: 

■ In the Enter Command box, enter: 

dupdate 1000 

This causes MWX-ICE to continuously poll the emulator for 
the value of led_port. 

Observe the variable led_port in the Data window and the 
LEDs on the evaluation board incrementing. 

> To exit dynamic update mode: 

■ From the toolbar, choose Stop to exit d 3 mamic update mode. 



Figure 17 Dynamic mode - Monitoring the variable led .port dynamically 

>- To dynamically modify the variable direct: 

1. From the Displays menu, choose Inspector. 

2. In the Inspect Symbol or Expression box, enter the following: 
direct 

The variable direct controls the direction of the demonstra¬ 
tor LED’s counting, either left or right. 
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3. In the Inspector window local menu, choose the long button 
to the left of the value left. 

This opens up a dialog box used to change the value of the 
inspected variable, shown in Figure 18. 



4. In the Enter new value field of the dialog box, type: 
right 

5. In the dialog box, choose Set to accept the new value. 

The Inspector window for direct should reflect the new value 
right, shown in Figure 19. Observe that the demonstrator 
LEDs are now decrementing. 
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Figure 19 Dynamic mode - Modifying a variable dynamically 


> To exit dynamic run mode and return to pause mode: 

1. In the Enter Command box, enter: 
dstop 

This forces SuperTAP from d 3 nniamic run mode back into 
pause mode. 

2. Close the Data and Inspector windows. 
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Example 13 - Displaying and modifying memory 

MWX-ICE provides means for acting on a block of memory. 
Using either the command line or the Memory Commands 
notebook, you can clear, move, set, read, write, or log a block of 
memory. 

> To restart the Cdemon program: 

■ From the File menu, choose Restart. 

> To display memory: 

1. From the Displays menu, choose Memory. 

2. In the Start Address box, enter: 

&led_port 

This displays a block of memory beginning with the address 
oiled_port. 

3. From the View menu, choose Show ASCII. 

This displays the ASCII values for the corresponding mem¬ 
ory data. 

> To manipulate a block of memory: 

■ From the Notebooks menu, choose Memory Commands. 

The Memory Commands menu provides the following tools for 
working with memory: 

□ Copy—copy the contents of one block of memory to another. 

□ Fill—^fill memory with a given value. 

□ Compare—compare the contents of two memory blocks. 

□ Search—search through memory for a pattern. 

□ Examine stack—display values from a particular stack 
level. 
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Conclusion 



Thank you for using the Applied Microsystems SuperTAP. 

Now that you have completed the demonstration of SuperTAP 
with MWX-ICE debugger, you can refer to the MWX-ICE User's 
Manual for more information about using the debugger. 

If this has been a SuperTAP pre-sales demonstration, please 
contact your local sales office for pricing and ordering 
information. 


Conclusion 
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AppencSxA 

Cdemon Demonstration Program 


Cdemon is the Applied Microsystems standard C/C++ 
demonstration program, providing examples of many code and 
data constructions used by programmers. An in-memory 
representation of the LEDs (led__port) may be used to see the 
output of some of the functions. 

Cdemon is composed of two discrete programs. The default C 
program writes to the LEDs and plays a simple hand of 
blackjack. The other, a C++ program, simulates an elevator. A 
variable named whichjiemo determines which of the two 
demonstration programs is executed. The card game program 
runs by default. If whichjiemo is set to 1, then the elevator 
program is executed. 

Afunctional block of the LED-lighting/blaclgack game is shown 
in Figure 20. 


Cdemon Demonstration Program 


67 




C START ) 



Figure 20 Rowchart of Cdemon 


initialO 

The function initiaK) initializes the three global LED-control 
variables, speed, and direct. These variables control 

the byte pattern, the speed, and the direction of LED pattern 
rotation, respectively. 

After initializing the global variables, initialO passes control to 
stepO. 

stepO 

The function stepO performs five loops of a simple LED control 
process, and passes control to dataO. 
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StepO declares the loop-control variable loops. In each of its five 
loops, stepO calls outledO 17 times, each time passing outledO 
a one-byte argument which represents the pattern displayed 
on the demonstration board LEDs. 

OutledO then writes the pattern to the LEDs (pointed to by 
dotjport) and to an in-memory representation of the LEDs 
(s 3 nnbohcally named ledjport). Each of the 17 arguments 
passed to outledO by each loop in stepO represents one LED 
pattern. 

While the execution of stepO can be observed with the trace 
function, the purpose of stepO is to demonstrate, in a single- 
stepped fashion, the relationship between the code and the 
LEDs. 

The most basic control of stepO comes from single-stepping 
while observing and modifying the loop-control variable loops. 
Loops may be observed with the Data window, and observed or 
changed with the Inspector window. Setting loops to a high 
value will lengthen the time spent in stepO, while setting loops 
to zero will very quickly cause program control to be passed to 
dataO. 

Because stepO produces a repeating cycle of data on the bus, 
predictable data-value conditions are available to the event 
system. 


dataO 

The function dataO plays a five-handed game of blackjack with 
four players and a dealer. When the game is won, dataO passes 
control to run(). DataO requires no input and generates no 
output, and is simply a code environment with interesting data 
structxires. 

The primary data structures are: 

1. card, a structure defining the value and suite of each card. 

2. player, a structure containing each player's name, a hand 
(array) of five cards, a point total, and a card count. 
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3. cardjieck, a union with various array types describing the 
cards in the four suits, the cards in the two sub-decks for 
shuffling, and the cards in the shuffled deck. 

After the declarations, dataO initiahzes player names and sets 
cards dealt and points for each player to zero, then executes the 
following functions. 

initO 

This function initializes players and dealer structures. 

sort() 

This function sets up a 52-word block of memory as a deck of 
cards. 

shuffleO 

This function divides the deck into two 26-word blocks and 
interleaves them, simulating the shuffling process. 

deal() 

This function deals one card to each player, including the 
dealer. 

hrtO 

This function deals cards to each player until points >= 18, or 
cards dealt = 5. 

houseO 

This function deals cards to the dealer until points >= 17, or 
cards dealt = 5. 

The players each draw for cards while they have less than 21 
points and more than 18 points. The dealer uses a similar 
routine to draw cards until his hand contains more than 17 
points. The game concludes after one round. 

The dataO function only executes once. To replay the game, 
reset the program to return to the beginning of the code, and 
run the code until it reaches a temporary breakpoint set at the 
beginning of the dataO function. 
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runO 

The function run() writes a string from left to right (or right to 
left, depending on the value of the variable direct) to the LED^s 
endlessly. Rather than using separate statements like stepO, 
nm() uses a ‘Svhile” control structure under the direction of the 
speed and direct variables from initialO. Program control stays 
with rimO. 

Run() declares external functions outledO and wait(), declares 
the byte maskbit, the integer cputype, the loop-control variable 
i, and the constant/brcycr = 1. 

outledO 

This function writes an 8-bit value to the LEDs (pointed to by 
dot_j)ort) and to led__port, the in-memory representation of 
LEDs. 

wait() 

This function sets the actual delay according to the value of two 
arguments, cputype and speed. 

The mechanics of run() can be observed by changing the values 
of direct and speedy and then running without breakpoints. The 
effects of changed variables in the LED-control task can be 
observed directly at the LEDs or at the Data window while 
monitoring led j)ort. 
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Need help? Call Customer Support at 1-800-ASK-4AMC for assistance. 
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Micfosystems 

Corporation 

Applied Microsystems Corporation maintains a worldwide network of direct offices committed to 
quality service and support. For information on products, pricing, or deliveiy, please call the nearest 
office listed below. In the United States, for the number of the nearest local office, call 1-800-426-3925. 

CORPORATE OFFICE 

Applied Microsystems Corporation 
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(206) 882-2000 
1-800-426-3925 
Customer Support 
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44 (0) 296-625462 
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Applied Microsystems Japan, Ltd. 
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1-8-1 Shimomeguro 
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81-3-3493-0770 
FAX 81-3-3493-7270 
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